1. Technical Field of the Invention
The present invention relates to electronic commerce transactions, and more particularly, to a method and apparatus enabling validated electronic commerce transactions between an originator, a recipient and a transaction administrator.
2. Description of Related Art
The increasing use of electronic media, such as the Internet, smart phones, screen phones and television with World Wide Web access, have expanded the opportunities for electronic commerce. In electronic commerce two or more entities electronically process specific tasks related to commerce ranging from purchase and payment to real estate transactions. Financial examples of electronic commerce include purchase and payment transactions. Purchase transactions are performed using credit and debit cards. Payment transactions are performed in paying bills, sending refunds on return merchandise, sending awards, etc.
A common set-up for commercial (including electronic) transactions is illustrated in FIG. 1. The transaction includes processing steps taking place between three entities, namely, a client 10, a merchant 20 and a payment authority (PA) 30. A delivery system between the client 10, merchant 20 and a PA 30 exists so that the steps required for transactions can be performed properly.
FIG. 2 is a flow diagram generally illustrating the steps involved in a commercial transaction. In step 12, the client 10 places a purchase order to the merchant 20. The purchase order will include the item(s) the client desires to purchase and payment information on an account from which to purchase the item. This purchase order may be for goods, services or any other item normally involved in commercial transactions. When a purchase order is received by the merchant 20, the merchant sends at step 13 a request for payment authorization to the payment authority (PA) 30.
Inquiry step 14 determines whether or not the purchase is authorized at the
30. This step is performed by the processing equipment 35 associated with the PA 30. The PA 30 responds at step 15 with a confirmation and authorization for the payment amount once the payment information regarding the client 10 checks out. If the payment information is not confirmed with the PA 30, the PA transmits a rejection at step 16 for the requested purchase authorization transaction. Upon confirmation of the transaction, the merchandise is delivered to the client 10 at step 17. Upon rejection of the transaction, the merchant 20 notifies the client 10 of the denial of authorization by CCA 30 at step 18. The sequence of steps 12, 13, 14, 15, 16, 17 and 18 must occur within some type of traceable delivery system.
The delivery system between the client 10 and the merchant 20 can be a regular mail system, telephone system, computer network or any other delivery system like UPS or Federal Express. The delivery system between the client 10 and the merchant 20 must also have some tracking capability. The delivery system between the merchant 20 and the CCA 30 is typically a private network providing Point-Of-Sale (POS) processing. All necessary information is transferred between two or more points in this network with a tracking mechanism that can follow the transactions. All of the above steps can also be executed within electronic commerce transactions.
However, in electronic commerce it is not possible to properly authenticate entities and transactions. In order to properly authenticate entities such as a client 10 and the merchant 20 performing a transaction, there is proposed a standard SET (Secure Electronic Transactions) in which each entity obtains a Certificate of Authentication from a Certificate Authority (CA) whereby clients and merchants can authenticate each other before performing any transaction by digitally signing the contents of the transaction and having the digital signature authenticated by the CA. This open exchange of digital signatures increases the potential of fraud. Thus, there is also a need for secure electronic commerce where the exchange of digital signatures between entities is eliminated.
An unauthorized client can send in a purchase order with an address to which to deliver the goods and no proper tracking can be established to validate whether or not an authorized client has initiated the purchase order. The PA 30 cannot establish whether the request from merchant 20 is initiated by the true client 10 or an unauthorized client. It is possible that a purchase order was never actually generated by an authorized client 10 but by someone else at the merchant's place of business. Additionally, the amount of the authorization can be changed or inflated by the merchant 20 and thus become an invalid request. The PA 30 does not know the real amount requested by the authorized client 10 and does not have any mechanism to confirm this information. Finally, the delivery address could be different from the actual address of the client 10, and the true client would not receive the merchandise, just the bill. Furthermore, there is no tracking system for automatically validating electronic transactions. Because of these issues, electronic commerce is a risky proposition.
In today's electronic banking, payment transactions take place by sending payment requests to a bank or third party to create electronic checks. The bank then makes payment to the client's payee or third party then sends the electronic check to the client payee. However, since the client's name, bank A.B.A. number and account number are easily accessible, it is easy for an unknown third party to create fund transfers even though data can be exchanged securely between the client and the bank. Furthermore, electronic check processing still has to be carried out as shown in FIG. 12 where PA 30 is a Banking System. Electronic commerce on the Internet is still a risky business because by federal statute, the bank is liable for this kind of fraudulent transaction. There is therefore a need to provide validated banking transactions over the Internet.